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ABSTRACT 

Preparing the Deep Space Network (DSN) 
stations to support spacecraft missions 
(referred to as pre-cal, for pre-calibration) is 
currently an operator and time intensive 
activity. Operators are responsible for sending 
and monitoring several hundred operator 
directives, messages, and warnings. Operator 
directives are used to configure and calibrate 
the various subsystems (antenna, receiver, 
etc.) necessary to establish a spacecraft link. 
Messages and warnings are issued by the 
subsystems upon completion of an operation, 
change of status, or an anomalous condition. 

Some portions of pre-cal are logically parallel. 
Significant time savings could be realized if 
the existing Link Monitor and Control system 
(LMC) could support the operator in 
exploiting the parallelism inherent in pre-cal 
activities. Currently, operators may work on 
the individual subsystems in parallel, 
however, the burden of monitoring these 
parallel operations resides solely with the 
operator. Messages, warnings, and directives 
are all presented as they are received — 
without being correlated to the event that 
triggered them. 

Pre-cal is essentially an overhead activity. 
During pre-cal, no mission is supported, and 
no other activity can be performed using the 
equipment in the link. Therefore, it is highly 
desirable to reduce pre-cal time as much as 
possible. One approach to do this, as well as 
to increase efficiency and reduce errors, is the 
LMC Operator Assistant (OA). The LMC OA 
prototype demonstrates an architecture which 


can be used in concert with the existing LMC 
to exploit parallelism in pre-cal operations 
while providing the operators with a true 
monitoring capability, situational awareness 1 
and positive control 2 . This paper presents an 
overview of the LMC OA architecture and the 
results from initial prototyping and test 
activities. 

BACKGROUND 

The Operator Assistant (OA), a multi-year 
applied research project currently in its second 
year, is investigating the application of 
Artificial Intelligence (AI) based automation 
techniques to ground data systems operations. 
The problem of introducing automation into 
an existing operational system is a complex 
one, requiring a thorough understanding of 
the problem domain [1]. There is an almost 
overwhelming temptation to attack automation 
piecemeal, attempting to “fix” individual 
problems, rather than to view the system as a 
whole. 

Our approach to automation was to first 
perform an in-depth systems analysis: identify 
the functions performed by the current system, 
identify problems characteristic of the existing 
system, identify desired new features, and 
develop and evaluate various functional 
breakdowns (human vs. computer), and then 


1. Knowledge of the true slate & status of the system 
at all times 

2. a. For all control actions, there exists a means of 
positively verifying that the given action occurred as 
desired; b. the human can, at any time, return the system 
to manual control. 
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develop an architecture capable of supporting 
the future system. 

PROBLEM DOMAIN 

NASA’s Deep Space Network (DSN) is a 
world- wide network of large (26 to 70 meters) 
antennas and telecommunications equipment 
dedicated to the support of interplanetary 
spacecraft. The monitor & control systems for 
the network and the individual Deep Space 
Stations (DSSs) have evolved continually 
since the DSN was commissioned in the 
1960’s. However, the underlying architecture, 
which depends heavily on human operators, 
has changed little. 

After an evaluation of DSN monitor & control 
(M&C), the first area chosen for application of 
automation technology was the DSS M&C, 
and particularly the Link Monitor & Control 
(LMC) functions. 

In DSN terminology, the Link is the string of 
equipment, starting with the antenna, 
necessary to communicate with spacecraft. 
The DSN is a bent pipe which enables the 
spacecraft controllers to command their 
spacecraft and receive telemetry from the 
spacecraft. Each spacecraft requires a unique 
configuration of the DSN equipment in order 
to establish the link. The LMC operators are 
responsible for knowing which configuration 
is needed to support a particular spacecraft, 
any special test procedures or calibrations, and 
the sequence in which to perform the 
necessary actions. 

During the configuration period (which can 
last anywhere from 45 minutes to several 
hours), the LMC operators are responsible for 
identifying, parametrizing, and sending over a 
hundred operator directives to several 
different sub-systems and subassemblies, and 
monitoring several hundred messages, 
responses and warnings to determine the 
health, status, and performance of the link. 
During this time, the station and equipment is 
not available to support any other activities. 
For some types of operations, the amount of 
time spent performing pre-cals (2 hours) 
dwarfs the actual data collection time (15 
minutes). The goal of the Link Monitor & 
Control OA is to reduce the overhead 


associated with pre-calibrations and to 
increase operator efficiency. 

The operator’s job is difficult due to: 1) the 
lack of on-line access to procedural, schedule, 
and general purpose information; 2) an LMC 
architecture which does not allow operators to 
query subsystems and subassemblies for 
parameter values; 3) an architecture which 
decouples the monitor data from the display 
data so that there are inconsistencies between 
the two; 4) a keyboard-only input system 
which is both slow and error-inducing; 5) a 
directive vocabulary of over a thousand 
different directives without any form of stan- 
dardization; and 6) an architecture which is so 
overladen with false-alarms that system 
warnings are often ignored. 

Many of these deficiencies are the targets of 
on-going DSN upgrade activities. Therefore, 
the automation architecture developed for link 
monitor & control has to look beyond existing 
discrepancies, although it must take them into 
account for near-term implementations. 

ARCHITECTURE 

The LMC Operator Assistant architecture 
consists of five main processing modules, as 
depicted in Figure 1: 1) Parameter Selection; 
2) Dependency Network; 3) Display 
Generation and Interface Management; 4) 
DSN Interface; and 5) Reactive Monitor, 
Diagnosis, and Control. Each of these 
modules performs specific functions which are 
an integral part of LMC operations. These 
modules are supported by several data and 
knowledge bases and secondary processes 
such as logging and report generation. The 
main components of the OA are discussed in 
the following sections. 

Support Databases 

As with most Al-based systems, a substantial 
amount of effort must be devoted to 
interfacing the support information and 
transforming it into a computer-readable and 
usable format [2; 3). For the Operator 
Assistant, this required creating and organiz- 
ing data and knowledge bases to contain the 
information currently used by the operations 
personnel. For example, the operators now 


123 




use a variety of inputs to determine exactly 
how they will perform a given activity. These 
inputs include daily schedules which identify 
what and when to perform activities. Sequence 
of Events (SOEs) which give detailed 
sequencing information and time critical 
information (e.g. Acquire the spacecraft at 
time t=day: :hour:min:sec), and Predicts, 
which are specific predicted values necessary 
to communicate with the spacecraft (e.g. 
position, transmitter frequency). Currently, 
this information is available to the operator 
primarily in hardcopy format — with little or 
no capability to edit, sort, filter, or transfer it 
on line. This results in the operators often 
having to manually enter large tables of data. 
Future upgrades are looking at making this 
information available on line. However, part 
of the OA architecture is to define a preferred 
representation format for this data. 


Knowledge Bases 

The key knowledge bases in the OA 
architecture are the Directives Knowledge 
Base (KB) and the Dependency Network 
Library. The Directives KB identifies each of 
the directives used to communicate with the 
subsystems and subassemblies. The basic 
information includes the directive name, 
description, parameters and directions for 
filling the parameters, expected responses, 
associated monitor functions, and time-out & 
clock information. 

The individual dependency networks, stored 
in the Dependency Network Library, contain 
the information to configure, calibrate, test, 
and operate the link. Each network is com- 
prised of operator directives, the post- and 
pre- conditions associated with a particular 
pass, and the predecessor and successor rela- 


124 




tionships between nodes. 

Dependency Network Module 

The Dependency Network Module initializes 
the dependency network defined in the library. 
First, temporal constraints are overlayed on 
the network resulting in a Temporal Depen- 
dency Network (TDN). The Parameter 
Selection Module then sets the values of 
directive parameters based on the most up-to- 
date information available. Finally, the TDN 
is passed to the Monitor, Diagnosis & Control 
Module for execution. 

The contents of each node in the network 
include the sequence of directives needed to 
accomplish the node, the values of any 
parameters which are predetermined by the 
type of choice of activity, preconditions, 
postconditions, and predefined contingencies. 

The TDN is a logical representation of the 
activity. It includes all of the required steps, 
and also identifies optional/desired steps, and 
sub-optimal operating conditions. It is a 
standardized, yet flexible representation of a 
DSN activity which incorporates the 
knowledge of the operations, engineering, and 
science personnel. 

Reactive Monitor, Diagnosis & Control 

The Reactive Monitor, Diagnosis, and Control 
Module is the centerpiece of the Operator 
Assistant architecture. It is responsible for 
scheduling the execution of the TDN 
directives, queuing them for execution, 
spawning the monitor and timing functions 
associated with each directive, collecting and 
distributing responses, detecting & diagnosing 
anomalies in TDN execution, recommending 
repair strategies, and replanning TDN 
execution when necessary. 

This module was implemented using a 
blackboard architecture, as shown in Figure 2. 
The scheduler, queue manager, monitor 
manager, response and directive classification 
and disbursement, and clock manager 
functions have all been implemented as part of 
the blackboard. 

The blackboard paradigm is a general-purpose 


architecture which can support a number of 
different types of applications including 
monitoring and diagnosis [4; 5], problem 
solving [6], and intelligent tutoring [7], For the 
Operator Assistant, we used the blackboard 
not only to exchange knowledge about the 
system in order to support monitoring and 
diagnosis, but also as a mechanism for 
controlling the link equipment and interfacing 
to the DSN. 

Display & Interface Management 

The Display Generation Interface Manage- 
ment module is responsible for ensuring that 
the human operators see the information 
needed to perform their functions in the 
system. The goals are to 1) ensure that the 
human operator at all times can determine the 
health, status, configuration, and performance 
of the link, and 2) ensure that the human 
operator can at any time intervene in an 
operation in progress and return it to manual 
control. 

DSN Interface 

The DSN Interface module is the 
communications interface to the DSN Local 
Area Network (LAN) for monitor & control. 
This module is responsible for 1) acquiring 
information off the LAN, formatting it, and 
delivering it to the Operator Assistant, and 2) 
performing the inverse functions to allow the 
Operator Assistant to send control information 
across the LAN. 

STATUS 

The Operator Assistant Prototype, Version 
1.0, was developed on a Macintosh II system, 
using Common LISP. The five primary 
modules and the portions of the supporting 
knowledge and databases required for the 
demonstration domain were implemented, 
integrated and tested in a laboratory setting. 
The diagnostician is currently being designed 
and will be incorporated into the next version 
of the OA prototype, to be released in 
September 1991. 

The laboratory test of the Operator Assistant 
was accomplished using a SUN 3 computer 
running a subsystem response simulator which 
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Figure 2. MONITOR, DIAGNOSIS, & CONTROL BLACKBOARD 


was written in C. The Operator Assistant and 
Response Simulator were- connected using 
Ethernet running TCP/IP. The tests 
demonstrated that the OA Prototype 
Architecture was appropriate and would meet 
system requirements. However, the test also 
highlighted some networking and memory 
management problems which will be 
addressed during the transition to the next 
version of the OA Prototype. 

DEMONSTRATION DOMAIN: VLBI 

The Operator Assistant was demonstrated for 
the Very Long Baseline Interferometry 
(VLBI) domain. VLBI is essentially a 
positioning technique which uses triangulation 
techniques to very accurately determine 
spacecraft velocity vectors. To perform a 
VLBI track, the DSN must configure two 
Deep Space Stations (located a continent 
apart) to the exact same configuration. Using 
differences in the phase and timing parameters 
of incoming signals, the VLBI scientists use 


differencing techniques to extract the desired 
data type. 

VLBI operations are extremely difficult for 
operators because 1) they are not performed 
often, 2) they require the link equipment to be 
configured in a way different from standard 
telemetry and commanding activities, and 3) 
the underlying scientific theory for VLBI is 
difficult to understand in the context of 
operational options. Because of these 
characteristics, and the user-documented need 
for improving in VLBI performance through 
operability enhancements, the VLBI domain 
was chosen to demonstrate the OA. 

The TDN for a VLBI 3 pass was developed. It 
incorporated procedural information gathered 

3. Specifically, a VLBI Delta-DOR (Double Differeniial 
One-Way Ranging) pass for the Galileo spacecraft using 
the 70-metcr anienna (DSS-14) at the Goldstonc Deep 
Space Communications Complex. The TDN would be 
slightly different for other spacecraft, other antennas, or 
for other types of VLBI science activities. 
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Figure 3. VLBI TEMPORAL DEPENDENCY NETWORK 


from the published documentation, the link 
operations personnel at the Goldstone Deep 
Space Communications Complex, DSN 
systems and subsystems engineering 
personnel, and the VLBI scientists. The TDN 
shown in Figure 3 is a high-level overview of 
a VLBI pass. It represents the first time that 
all of the different components of a 
operational procedure were collected in the 
same place and the constraints, dependencies, 
and desired features explicitly stated. 

CONCLUSION 

The Operator Assistant prototype concept & 
architecture was the result of an in-depth 
analysis of how Al-based automation 
techniques could be incorporated into DSN 
operations. DSN operators, and specifically 
LMC operators, are part of a complex human- 
machine system which places a heavy burden 
on the human portion of the system to make it 
all work. The Operator Assistant is the first 
step in creating a new functional distribution 
between the operators and the systems they 
control and use. In this environment it is very 


difficult to improve monitoring without first 
improving the underlying control structure — 
we have attacked the problem from both sides 
to address the issues of situational awareness 
and positive control. The resulting system has 
been demonstrated in a laboratory setting and 
is currently being upgraded to be 
demonstrated in a real-time operational 
environment. 
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